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I. Introduction 

The NASA Langley Research Center (LaRC) Systems Analysis & Concepts Directorate (SACD) began 
studying human exploration missions beyond low Earth orbit (LEO) in the year 1999. This included 
participation in NASA’s Decadal Planning Team (DPT), the NASA Exploration Team (NExT), Space 
Architect studies and Revolutionary Aerospace Systems Concepts (RASC) architecture studies that were 
used in formulating the new Vision for Space Exploration. In May of 2005, NASA initiated the 
Exploration Systems Architecture Study (ESAS). The primary outputs of the ESAS activity were concepts 
and functional requirements for the Crewed Exploration Vehicle (CEV), its supporting launch vehicle 
infrastructure and identification of supporting technology requirements and investments. An exploration 
systems analysis capability has evolved to support these functions in the past and continues to evolve to 
support anticipated future needs. 

SACD had significant roles in supporting the ESAS study team. SACD personnel performed the liaison 
function between the ESAS team and the Shuttle/Station Configuration Options Team (S/SCOT), an 
agency-wide team charged with using the Space Shuttle to complete the International Space Station (ISS) 
by the end of Fiscal Year (FY) 2010. The most significant of the identified issues involved the ability of the 
Space Shuttle system to achieve the desired number of flights in the proposed time frame. SACD with 
support from the Kennedy Space Center performed analysis showing that, without significant investments 
in improving the shuttle processing flow, that there was almost no possibility of completing the 28-flight 
sequence by the end of 2010. 

SACD performed numerous Lunar Surface Access Module (LSAM) trades to define top level element 
requirements and establish architecture propellant needs. Configuration trades were conducted to determine 
the impact of varying degrees of segmentation of the living capabilities of the combined descent stage, 
ascent stage, and other elements. 

The technology assessment process was developed and implemented by SACD as the ESAS architecture 
was refined. SACD implemented a rigorous and objective process which included (a) establishing 
architectural functional needs, (b) collection, synthesis and mapping of technology data, and (c) performing 
an objective decision analysis resulting in technology development investment recommendations. The 
investment recommendation provided budget, schedule, and center/program allocations to develop required 
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technologies for the exploration architecture, as well as the identification of other investment opportunities 
to maximize performance and flexibility while minimizing cost and risk. 

A summary of the trades performed and methods utilized by SACD for the Exploration Systems 
Mission Directorate (ESAS) activity is presented along with how SACD is currently supporting the 
implementation of the Vision for Space Exploration. 


II. Exploration Systems Analysis 

The goals of exploration systems analysis are to formulate innovative and sustainable mission 
approaches, develop associated system and architecture concepts, and provide related technology 
requirements that will enable these missions to be implemented to meet ESMD program objectives. This 
includes assessments of “disruptive” technologies that could significantly alter exploration architecture 
implementations. Future scenarios are assessed from an integrated systems perspective to both define 
technology requirements and assess technology impacts. Quick response systems analysis in support of the 
ESMD will also need to be performed as required. 



Figure 1. Elements of Exploration Systems Analysis. 

Exploration systems analysis embodies a process composed of interrelated hierarchical elements that is 
extremely iterative in nature. A high level vision is needed to provide context from which to generate 
approaches for achieving derived goals and requirements. These “approaches” are generally thought of as 
architectures made up of various systems and concepts that embody distinct concepts of operations. 
Technology areas (sometimes referred to as “enabling capabilities” such as propulsion and structures) are 
identified to bound performance requirements. Individual technologies that support the technology areas 
are then assessed with respect to the desired performance requirements, readiness levels, and development 
cost. Results from the technology assessment are then used to guide investment strategies and to insert 
back into the architectures to assess projected technology performance as compared to the original 
technology area assumptions. Analytical tools that link the fundamental vision through the architectures, 
supporting systems, and technologies, down to basic physics, support the above analysis process. 

A. Vision 

“A vision is a cognitive image of the future which is positive enough to members so as to be motivating 

and elaborate enough to provide direction for future planning and goal setting. ” 

—Thomas/Greenberge 
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In January of 2004, the President announced to the nation and the world his vision for NASA in the 
form of his Exploration Initiative. This strategic vision conveys a general philosophy to be followed now 
and in the future. Before this vision was established, NASA based its capability investment strategy upon a 
diverse set of future scenario studies that were performed independently of each other with inconsistent 
linkage to goals and requirements along with widely varying technology assumptions. No integrated view 
of the future could be established, and integrated costing was not possible — yielding a “shopping list” of 
capabilities that were difficult to cost and prioritize. 

B. Goals and Requirements 

Well-established goals and requirements, along with a range of associated funding wedges and time 
periods, help focus the solution trade space. Systems analysis requires an integration function to formulate 
assumptions, establish metrics, normalize technology performance assumptions, ensure connectivity, and to 
facilitate cost and risk assessments. Agency-wide teams can then be created to develop architectures, 
advanced concepts, perform technology assessments and develop investment recommendations. An 
integration team manages, monitors, and coordinates the above activities to facilitate: 

• Consistent and direct linkage to goals and requirements, 

• Consistent technology assumptions, 

• Integrated mission scenarios, and 

• Integrated cost and risk assessments from the start of the process, 

The net products are integrated architectures and enabling capabilities tied directly to the Vision for Space 
Exploration supported by investment priorities and associated budget profiles. Systems analysis is applied 
in the above context across a large mission space in support of the Vision for Space Exploration as depicted 
in Figure 2. 
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Figure 2. Missions in Support of the Vision for Space Exploration 
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C. Strategic Analysis 

Managing the development of large, complex systems from a strategic perspective presents a number of 
unique challenges. As the scope of systems become larger and more complex, as with the developmental 
exploration system, it becomes increasingly more difficult to integrate analysis at the system level. 
Complex systems, often referred to as “system of systems”, are characterized by the fact that they are 
typically made up of a number of individual component systems, each of which has independent goals and 
can be discretely analyzed for performance, cost, and risk using detailed operational models. 

Strategic management of these systems is difficult in that they are composed of a set of component 
systems that, while they operate independently, typically have multiple interdependencies that control the 
behavior of the global system. Because of these interdependencies, it is not possible to simply evaluate 
each component system separately and to then integrate the results. The global system must be evaluated 
as a whole in order to accurately predict behavior. However, it is typically not desirable, or even possible, 
to develop a single, holistic model of the global system. Such a model would be overly complex and 
would duplicate the capability of analysis models that already exist. 

In fact, the goal of a strategic analysis capability is not to replace analysis at the component system 
level, but rather to provide a framework to integrate independent analysis of multiple system components. 
It is assumed that accurate models/descriptions/defmitions of the individual systems exist at the component 
level. These models have the capability to independently evaluate the performance, cost, and risk of each 
component in a deterministic manner. 

D. Architectures and Advanced Concepts 

Architectures consist of the integrated set of functional building blocks that describe the method by 
which a set of activities are carried out to accomplish specified goals. The functional building blocks take 
the form of advanced systems concepts that are built upon technologies that are often referred to as 
enabling capabilities. Candidate mission architectures and system concepts will be modeled to allow 
systems analysis and trade studies. These studies will determine the effectiveness of the various system 
concepts in implementing the preferred system architectures and providing the desired functional 
capabilities. The key enabling capabilities required will be identified as a product of the trade studies, 
including desired performance levels. Analyses conducted will address not only performance, but cost, 
risk, and safety considerations. 

E. Technology Assessment 

One of the four goals outlined in The President’s Vision for Space Exploration is to “develop the 
innovative technologies, knowledge, and infrastructures both to explore and to support decisions about the 
destinations for human exploration”. This goal was strengthened by the findings of the “President’s 
Commission on Implementation of United States Space Exploration Policy” headed by Pete Aldridge. One 
of the key findings of the Commission states that “the successful development of identified enabling 
technologies will be critical to the attainment of exploration objectives within reasonable schedules and 
affordable costs.” In addition, one of the four major tasks of the recently completed Exploration Systems 
Architecture Study (ESAS) was to “identify key technologies required to enable and significantly enhance 
exploration systems and reprioritize near-term and far-term technology investments” using systems 
analysis. While the architecture and advanced concepts analysis refines architecture requirements, 
associated system concepts, and the related enabling capabilities; the technology assessment process 
connects the architectures to technology investment strategies through systems analysis. 

The technology assessment process derives technology requirements from exploration architecture 
functional needs, develops and maintains a technology and mission database, and establishes a formalized 
approach for developing prioritized technology investment portfolios that are directly traceable to 
exploration architecture needs through systems analysis. The technology investment portfolios provide 
budget, schedule, and center/program allocations required to develop technologies for the exploration 
architecture. It identifies investment opportunities to maximize performance and flexibility while 
minimizing cost and risk. 


F. Analysis Environment 

A strategic systems analysis environment is required to enable distributed groups of participants to 
share information and solve problems in a consistent and managed way. Both local and remote users are 
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able to upload and download data through common interfaces. Users can communicate and interact with 
each other in real time and they transfer data and analysis at whatever time is convenient for them. The 
environment captures the study process electronically in order to build databases to facilitate report 
generation and enhance design knowledge capture. A degree of device independence is necessary to 
maximize the ease at which remote users can be brought into the environment. Security of the environment 
must be maintained in order to protect sensitive or proprietary data. The assessments presented in this 
paper were developed in environments with the above characteristics although it must be noted at the 
current time that NASA has yet to implement such a capability across the agency. 


III. International Space Station (ISS) Assembly Sequence Assessment 
A. Introduction 

The Vision for Space Exploration, announced in February 2004 by President George W. Bush, and 
NASA’s resultant Level 0 Exploration Requirements provide several items of direction regarding the 
completion and operation of the International Space Station (ISS). In particular these documents provide 
direction that: 

1. NASA shall complete assembly of the ISS, including US components that support US space 
exploration goals and components provided by foreign partner elements, planned for the end of 
this decade; 

2. NASA shall retire the Space Shuttle as soon as assembly of the International Space Station is 
completed, planned for the end of this decade; 

3. NASA shall focus US ISS research and technology on supporting exploration goals; 

In addition, past direction has been given that all programs will be run in a manner consistent with 
safety concerns and the recommendations of the Columbia Accident Investigation Board (CAIB). 

In response to these requirements the ISS and Space Transportation System (STS) program offices have 
developed a 2 8 -flight shuttle sequence to complete station assembly, to provide partial resupply, and to 
support utilization. This sequence has a planned completion date of December 2010. 

While the outlined flight sequence ostensibly meets the goals in the Exploration Vision and in the Level 
0 requirements, there are a number of risks that have been identified that could impact the ability to 
complete the current plan. The most significant of the identified risks involved the ability of the STS 
system to achieve the desired number of flights in the proposed time frame. 

Recent studies show that, without significant investments in improving the shuttle processing flow, that 
there is almost no possibility of completing the 28-flight sequence by the end of 2010. As shown in Figure 
3, there is at best an approximate 91% probability of accomplishing 19 Total Space Shuttle flights by the 
end of FY2010. As additional issues are considered, such as a failure to Return to Flight (RTF) as 
scheduled, External Tank (ET) availability issues, and ground infrastructure transfer at Kennedy Space 
Center (KSC) to support future exploration needs, the likely number of flights that can be achieved by the 
end of FY2010 decreases as shown. 
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Probability of Achieving 19 Flights by FY2010 
(with Likely Case set of Core MAST assumptions) 



Figure 3. Probability of Achieving 19 Space Shuttle Flights by the End of FY 2010 

The requirement to complete STS operations by the end of the decade is driven not only from a safety 
standpoint but also from a budgetary perspective. The current budget for exploration is predicated on the 
end of shuttle flights in 2010. Any extension of the shuttle retirement date would require either increased 
funding for NASA or a redirection of other funds within the agency, most likely those planned for 
exploration. 

The primary goal of this study was to explore options for reducing the total number of Shuttle flights 
and reducing the number of elements in ISS assembly. In addition, the study evaluated transportation 
options to support ISS in the post-assembly period. 

B. ISS-Transportation Analysis Model 

In order to explore the potential trades between station configuration, shuttle flight sequence, CEV 
flights, and partner vehicle flights, a model, illustrated in Figure 4, was constructed to evaluate vehicle 
traffic, ISS requirements, and ISS operations. The synthesis model is comprised of three components: 

• Transportation Module - A system model was constructed for ISS requirements and transportation. 
Based on an input shuttle flight sequence and other vehicle flight rates the model is able to calculate 
the ability of the transportation system to support station construction and resupply. The model 
specifically calculates mass and volume requirements in the following categories: 

Crew Support 

Pressurized Logistics & Maintenance (L&M) 

Unpressurized L&M Orbital Replacement Units (ORUs) 

Pressurized Utilization 
Unpressurized Utilization 
Propellent 

The model then loads these cargoes in a prioritized manner, accounting for accommodation factors 
and loading constraints, onto the available vehicles. The model accounts for changes in station 
altitude, storage capabilities, and flight timing constraints. A flight by flight accounting is kept of 
total delivered cargo (upmass and downmass) versus required values. 
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Figure 4. ISS-Transportation Analysis Model 
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The transportation module was directly adapted from the ISS Vehicle Integrated Performance, 
Environments, and Resources (VIPER) team’s ISS traffic model VIPER Effectiveness and 
Optimization Model VENOM, the tool used by the ISS program to perform long-term ISS resupply 
planning. 

Within the Transportation Module, achieved flight rates are input for all vehicles. Expected 
launch dates for the Shuttle were derived using the Manifest Analysis Simulation Tool (MAST). For 
each Shuttle flight sequence used, MAST was used to predict a “Likely Case” for expected launch 
dates, and a “Worst Case” for expected launch dates. These two cases were used in all analysis to 
bound the analysis. 

• Crew Time Module - The crew time module calculates the availability of crew time for various 
functions, including utilization, based on maintenance requirements and the input traffic plan. This 
calculation is accomplished by first calculating the total crew hours available from station crew and 
visiting vehicle crews and then subtracting all fixed crew time requirements (including: EVA, 
maintenance, vehicle unloading, training, medical, etc.). The remaining hours are then available for 
utilization. 


The crew time module is adapted from the VIPER team’s VENOM model. 


• Utilization Module - This module is used to determine if varying levels of desired utilization could be 
supported by a given traffic plan and station configuration. Within this module a given utilization 
goal is defined by: the number of International Standard Payload Racks (ISPR) required, the level of 
utilization resupply required, and the amount of crew time required. The utilization module compares 
these requirements to the station configuration including laboratory facilities, the permanent crew 
size, delivered ISPRs, and delivered resupply cargo, to determine if the utilization case can be 
completed. For this study, ESMD Case A utilization requirements were used for all analysis. This 
requirement set represents the utilization requirements to complete exploration research. 

The model accounts only for Upmass, Downmass, Crew Hours, and ISPRs. There is no specific 
analysis of gravity loads (G-Loads) or late access. 
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C. Description of Analysis Completed 

This study dealt primarily with the alternative involving reduced numbers of Shuttle flights, scaled back 
ISS configurations, and alternate vehicle development. 

As part of this analysis, three base Shuttle sequences and associated ISS configurations were initially 
evaluated (note-the number of Shuttle flights are always indicated with a “+1 ” added, the additional flight 
indicates a potential Hubble repair mission which would add to the total number of shuttle flights): 

A. 11+1 Shuttle Flights - No additional ISS elements beyond current configuration 

B. 17+1 Shuttle Flights - Current configuration plus full truss, Node 2, Japanese Experiment 
Module (JEM) Experiment Logistics Module - Pressurized Segment (ELM-PS), JEM 
Pressurized Module (PM), JEM Exposed Facility (EF), and Columbus Orbital Facility (COF) 

C. 22+1 Shuttle Flights - Current configuration plus full truss, Node 2, JEM ELM-PS, JEM PM, 
JEM EF, COF, and Node 3 

Within each case, the Shuttle sequence includes flights to assemble ISS, deliver outfitting, crew 
resupply, L&M resupply, and ORU pre-positioning. Specific Shuttle flights within each sequence are 
described in the case results below. The amount of cargo delivered varies between cases based upon the 
capacities of each flight. Alternate vehicles were used to meet any gaps in requirements not met by 
Shuttle. In all cases the full upmass requirements are met. 

Because of the desire to minimize any gap in U.S. manned spaceflight capability, all Shuttle sequences 
are conducted through FY2010. In cases where the sequence could likely be completed by an earlier date, 
the sequence is stretched so that the last flight will occur approximately at the end of FY2010. MAST 
analysis is used to predict likely launch dates for each sequence over this period. 

For each ISS-STS run, two expected shuttle flight rate cases are used for analysis. The first, the “likely” 
case, represents the anticipated results if daylight launch restrictions are lifted after the two RTF flights. 

The second, the “Worst” case, represents the anticipated results if all current constraints on shuttle flight 
rate remain in place. 

For each case, two sets of results are presented. The first chart shows the total required flight rates for 
all vehicles to support full ISS requirements. The second graph shows the total upmass requirement, 
including assembly mass, and the total upmass deliveries broken down by vehicle type. Because the 
upmass requirements, particularly for assembly, are driven by the shuttle schedule, the annual requirements 
can shift from case to case. 


D. Post- Assembly Traffic Strategies 

For each Shuttle/ISS case, two traffic strategies were evaluated: 

1 . Maximum CEV Case - Additional resupply and return requirements would bet met to the maximum 
extent possible through the use of CEV and CEV-derived vehicles. International Partners (IP) 
vehicles would be used only if already in the current plan (European Space Agency) ESA and JAXA 
supplied balance flights) or as required before CEV availability. The initial design used for CEV and 
CEV derivative vehicles is described in section 4 of this report. 

2. Maximum IP Case - Additional resupply requirements would bet met to the maximum extent possible 
through the use of IP vehicles. CEV-derived vehicles would be used only to supply downmass 
capability not available through IP flights. 

In both strategies, CEVs are used for USOS crew rotation. Soyuz are used to provide USOS crew 
rotation prior to CEV availability. 

E. Summary of Baseline Cases 

Table 1 summarizes the flight rate data for all of the baseline cases. 
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The results of the baseline case indicate that there are difficulties with both the 17+1 and the 22+1 
assembly sequences. The 17+1 sequence completes assembly and resupply but provides pre-positioning 
for only a very small number of ORUs. The lack of ORU pre-positioning not only increases post-assembly 
delivery requirements but also significantly increases the risk of ISS failure in the time period between 
shuttle retirement and CEV-unpressurized availability. 

11 + 1 17+1 17+1 22+1 17+1 17+1 22+1 

CEV MAX CEV MAX CEV MAX CEV MAX IP MAX IP MAX IP MAX 

Likely Likely Worst Likely Likely Worst Likely 


Space Shuttle 

11 + 1 

17+1 

17+1 

22+1 

17+1 

17+1 

22 + 1 

ATV 

0 

10 

10 

10 

10 

10 

10 

ATV (US Purchased) 

0 

0 

0 

0 

0 

0 

0 

HTV 

0 

8 

8 

8 

8 

8 

8 

HTV (US Purchased) 

0 

0 

0 

0 

22 

22 

12 

Soyuz (US Purchased) 

5 

9 

9 

9 

9 

9 

9 

Progress (US Purchased) 

5 

15 

16 

10 

11 

12 

13 

CEV-Crew 

6 

11 

11 

11 

11 

11 

11 

CEV-Pressurized Cargo 

12 

15 

15 

16 

5 

5 

5 

CEV-Unpressurized Cargo 

2 

5 

5 

4 

0 

0 

0 

HLLV 

0 

0 

0 

0 

0 

0 

0 

TOTAL USOS Flights 

41 + 1 

90+1 

91 + 1 

90+1 

93 + 1 

94+1 

90 + 1 


Ariane Transfer Vehicle (ATV), H-II Tranfer Vehicle (HTV), Heavy Lift Launch Vehicle (HLLV) 

Table 1: Summary of Baseline Case Flight Rates 

The 22+1 sequence provides adequate ORU pre-positioning. However, there is some possibility that 23 
flights could not be completed by the end of FY2010. The MAST results indicate that using the likely case 
assumption, 23 flights could only just be accommodated. Any deviation from those assumptions would 
reduce the number of available flights. 

F. Additional Analysis 

The results of the base cases showed that with 17+1 Shuttle flights, a large number of unpressurized 
logistics flights were required in the post-assembly period to deliver the required number of ORUs. In 
addition, there is some likelihood that certain critical ORUs could fail before they could be delivered by 
alternate vehicles. For both these reasons, it is desirable that a significant number of ORUs be pre- 
positioned using the Shuttle. 

Thus, an additional case was developed that added two additional unpressurized logistics flights to the 
17+1 flight sequence case. These two additional flights would deliver a substantial number of additional 
ORUs, reducing post-assembly requirements and reducing risk of ORU failure. 

Table 2 shows the flight sequence and launch dates used for the 19+1 Space Shuttle flight sequence. 
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# 

Flight 

Likely 

Worst 

1 

LF1 - RTF1 

2005 

2005 

2 

ULF1.1 -RTF2 

2006 

2006 

3 

12A-P3/P4 

2006 

2006 

4 

12A.1 - P5/Pres Logistics 

2006 

2007 

5 

13A-S3/S4 

2007 

2007 

6 

13A.1 - S5/Pres Logistics 

2007 

2007 

7 

15A-S6 

2007 

2007 

8 

10A - Node 2 

2007 

2008 

9 

ULF2 - Outfitting 

2007 

2008 

10 

1E-COF 

2008 

2008 

+1 

Hubble Servicing Mission 

2008 

2008 

11 

1 J/A - ELM-PS/SPDM 

2008 

2008 

12 

1J - JEM PM 

2008 

2009 

13 

17A - Outfitting/Logistics 

2008 

2009 

14 

ULF5 - Rails/Unpres Logistics 

2009 

2009 

15 

19A - 6-Crew Capacity 

2009 

2010 

16 

ULF6 - Unpres Logistics 

2009 

2010 

17 

2 J/A - JEM EF/Rails 

2010 

2010 

18 

Unpres Logistics 

2010 

2010 

19 

Unpres Logistics 

2010 

2010 


Table 2: 19+1 Flight Shuttle Sequence 


G. Conclusions 

The current 28-flight sequence is unlikely to be completed by the end of 2010. The extension of shuttle 
program beyond that date would result in a major impact to the budget available for exploration and, in 
turn, the completion of exploration requirements themselves. 

Aside from procurement of alternate transportation and greatly accelerating Shuttle processing, the only 
methods to gain any assurance of Shuttle retirement in the 2010 timeframe is to eliminate flights from the 
proposed sequence, either through reduction in delivery of utilization and ORUs or by removing elements 
from ISS assembly. 

There are reduced final ISS configurations that meet commitments to ESA and JAXA and have the 
potential to reduce the number of planned flights required by up to 1 1 flights. These configurations have 
only a small impact on the total potential utilization that could be completed on-board the ISS. 


III. Lunar Lander Concept Definition Activities within the NASA LaRC 
Systems Analysis and Concepts Directorate 

The NASA Langley Systems Analysis and Concepts Directorate (SACD) has extensive experience in 
the conceptual design and analyses of lunar surface elements. In the summer of 2005, SACD was a lead 
participant in the NASA Headquarters-sponsored Exploration Systems Architecture Study (ESAS). The 
purpose of this study was to establish a viable lunar architecture concept and implementation plan 
supporting the Vision for Space Exploration. One SACD responsibility supporting ESAS was the 
development of innovative lunar lander concepts which provided valuable information for the selection of a 
reference lunar architecture. More recently, in the spring and summer of 2006, SACD was a lead 
organization participating in the Constellation Advanced Projects Office-sponsored Lunar Lander 
Preparatory Study. The purpose of this study was to extend the ESAS lunar lander analysis by assessing a 
wider range of lunar lander concepts considering updated requirements and specific trades and analyses. 
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A. ESAS Lunar Lander Studies 

LaRC SACD provided analyses of a range of “non-traditional” lunar lander concepts to support ESAS 
lunar architecture definition (Figure 5). For example, single-stage lander concepts with either pressure-fed 
or pump-fed engines were developed and evaluated vs. 2-stage, pressure-fed reference concepts. 
Configuration trades included number and size of engines. SACD also evaluated concepts which used the 
Crew Exploration Vehicle (CEV) as the habitable element of the lunar lander. For these “CEV-to-the- 
surface” concepts, configurations included the CEV Crew Module plus lunar lander ascent and descent 
propulsive stages. The range of SACD lunar lander analyses performed for ESAS included: concept 
definition, vehicle and system sizing, vehicle packaging, center-of-gravity analysis, engine gimbal analysis, 
Earth Departure Stage (EDS) and launch vehicle performance analysis, payload direct return capability 
analysis, and delta-V analysis as a function of thrust-to-weight. 



Horizontal, 1 -Stage, Vertical, 2-Stage, Vertical, 1 -Stage, Vertical, 2-Stage 

4-Engine, Pressure-Fed 4+2-Engine, Pressure-Fed 1 -Engine, Pressure-Fed “CEV-to-the-Surface” 


Figure 5. Examples of LaRC SACD-defined lunar lander concepts supporting ESAS architecture 

definition. 

B. Lunar Lander Preparatory Study Concepts 


The reference lunar architecture defined as a product of the ESAS activity is being further refined as the 
specific goals, needs and objectives of the Vision for Space Exploration are established. Objectives for 
lunar surface activities are also in the process of being developed by the Lunar Architecture Team (LAT), 
an Agency-wide team managed by the NASA Exploration Systems Mission Directorate (ESMD). Once the 
lunar surface strategic objectives are defined, they will be used as the basis for future exploration system 
studies that will, over the next several years, lead to the establishment of lunar exploration system 
requirements that will be used for detailed system definition. 

During the spring and summer of 2006, in parallel with the LAT lunar surface strategic objectives 
activity, several internal ESMD lunar exploration studies were performed to prepare for the receipt of the 
approved lunar surface objectives. An example of these studies, the Lunar Lander Preparatory Study 
(LLPS) was formulated to “pick up” where the ESAS team left off and incorporated programmatic 
directions received since the conclusion of the ESAS activity. Results from the LLPS will position the 
Constellation Program to be responsive to the lunar surface strategic objectives when provided by the LAT. 

The objective of the LLPS was to define innovative lunar lander approaches that meet a fixed 
requirement set and fall within specific bounding cases for trade studies. Each NASA Center-based lunar 
lander design team used common requirements and trade space boundaries to perform analyses and concept 
definition of innovative lunar lander designs. 

1. Phase 1 Concepts 

Phase 1 of the study explored multiple design concepts, including the relationship of the lander to 
potential surface systems. Products included refined descent stage propulsion system and payload 
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packaging options; refined ascent stage concepts including crew cabin layout, minimum volume options 
and propulsion system packaging; lander structural analysis; and launch vehicle packaging. 

LaRC SACD focused on lunar lander-level and lunar architecture-level trades during Phase 1 of the 
LLPS. Emphasis was placed on assessing architecture “closure” with respect to launch vehicle and Earth 
Departure Stage (EDS) performance. Also, LaRC SACD lunar lander design concepts were developed to 
enhance lunar surface operations for both sortie and outpost missions. This included establishing lander 
configurations that facilitate crew egress/ingress and cargo unloading/deployment. 

The LaRC SACD study methodology was based on establishing upper-bound and lower-bound 
examples of lunar lander concepts based on system mass and performance. Within these bounds, key trade 
parameters were defined and lunar architecture-level and lunar lander element-level trade studies were 
performed. Figure 6 illustrates the range of lander concepts developed by LaRC SACD during Phase 1 of 
the LLPS. 

With a mass estimate of 46.6 t, the Revised ESAS Lunar Lander is the LaRC SACD upper-bound 
example of a lunar lander concept. Updates from the ESAS lander concept include: 

• Sized for a 95-day low-Earth orbit loiter period prior to trans-lunar injection (vs. a 25-day 
period assumed during ESAS). This new requirement increases lander size since it 
significantly impacts the quantity of cryogenic propellant (LOX and LH2) which will boil off 
without active thermal control 

• Sized for smaller CEV based on revised CEV design analysis. This decreases lander size due 
to a lower lunar orbit insertion (LOI) propellant requirement (i.e., the lunar lander performs 
the LOI maneuver and “pushes” the CEV into lunar orbit; a smaller CEV results in a lower 
lander propellant requirement for this maneuver sequence) 

• Ascent stage engine geometry was revised based on the Service Module engine 

• Ascent stage propellant changed from LOX/CH4 to storable 

The 2-Stage, Split Habitat Lander is the LaRC SACD concept most similar to the revised ESAS Lunar 
Lander. Total mass for the sortie-mission configuration is 42 t. Mass savings vs. the revised ESAS Lander 
Lander is achieved by staging the pressurized element. That is, the pressurized element is divided into a 
minimum volume ascent stage habitat and a larger volume surface habitat. The ascent stage separates from 
the descent stage and surface habitat prior to lunar ascent resulting in an ascent stage requiring significantly 
less propellant than the revised ESAS Lunar Lander. Mass reduction is also achieved through the use of a 
nested, toroidal descent stage propellant tank. 

The Descent- Assisted Split Habitat (DASH) Lander is a 43.8 t concept which is reconfigurable to 
accommodate a dual habitat or cargo mission supporting a lunar outpost. This concept also includes a split 
habitat which reduces overall system mass and facilitates egress/ingress and cargo unloading/deployment. 
A key feature of the DASH lander is the use of a retro module to perform the lunar orbit insertion (LOI) 
maneuver and most of the descent to the lunar surface. At approximately 2 km altitude, this retro module is 
staged and the DASH lander module completes the propulsive descent profile. Another principal feature of 
the DASH lander is the use of an external “suitport” concept for EVA that eliminates the need for an 
airlock and mitigates lunar dust/habitable volume contamination issues. 

The Hybrid Global Lander (HGL) is a “lower bound” concept which was defined to explore a revised 
“minimum” mission concept for lunar exploration. For this lander concept, the HGL Crew Lander with 
minimal pressurized volume supports 2-crew, 7-day “mini-sortie” missions; the Crew Lander and a 
separate Habitat Lander support 4-crew, 28-day “super-sortie” missions. A Cargo Lander configuration has 
also been defined based on the HGL Descent Stage. Key features of the HGL concept include: global 
landing capability for mini-sortie missions, common elements used across the three lander configurations,, 
and landers leave behind re-useable assets for follow-on missions to the same location. A operations 
concept change vs. the ESAS reference concept is the use of the Earth Departure Stage (EDS) to perform 
the lunar orbit insertion (LOI) maneuver sequence instead of the lunar lander. 

The Unpressurized Crew Transport lander is another example of a “lower bound” lander concept. This 
concept is a two-stage lander which incorporates dockable, rear-entry space suits on an unpressurized 
ascent stage. The dockable, rear-entry EVA suits mitigate lunar dust/pressurized volume contamination 
issues and potentially provide enhanced crew safety and contingency options since the crew are in pressure 
suits during ascent and descent. For this concept, the EDS also performs the LOI maneuver sequence. 

The Horizontal, 1 -Stage Lander is a concept which is optimized for lunar surface operations. The 
horizontal design facilitates crew egress/ingress and cargo unloading/deployment (i.e., minimizes travel 
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distance to the lunar surface). Additionally, analysis performed jointly with the Jet Propulsion Laboratory 
demonstrated that this lander configuration is uniquely suited for the deployment of a 10 t surface fission 
power system proposed for a permanently crewed lunar outpost. An additional benefit of the horizontal 
lander configuration is that the LOX/CH4 propellant tank location provides inherent radiation protection 
during in-space transit and on the lunar surface. Similar to several other lander concepts, the EDS performs 
the LOI maneuver sequence for this lander concept. 
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Figure 6. LaRC SACD lunar lander concepts developed for the Lunar Lander Preparatory Study, 

Phase 1. 


2. Phase 2 Concepts 

Phase 2 of the study was based on downselected concepts from Phase 1. In this phase, performance 
estimates and design concepts were refined. Additionally, cost and risk analyses were performed using 
Constellation- sanctioned methods. Each lander team was given specific guidance and direction regarding 
Phase 2 concepts and products. 

LaRC SACD was directed to continue analyses of the DASH lander and horizontal lander concepts. 
Specific guidance for DASH analyses was to: improve analysis of trajectory and aborts, further develop 
concepts for deploying astronauts (alternatives to suitports); further refine drop stage operations, 
trajectories, altitude and velocity at staging; and further develop the small ascent/transport habitat stage. 
Guidance for horizontal lander analyses included: integrate horizontal lander concepts using all multi- 
center team members who contributed horizontal concepts; fully develop horizontal lander concepts 
including launch and landing; and investigate payload unloading options. A description of the DASH and 
horizontal lander configuration revisions in Phase 2 is provided below. 

The Phase 2 DASH concept is illustrated in Figure 7. Configuration changes from the Phase 1 DASH 
concept include: 

• Changed Surface Habitat diameter from 4 m to 3 m to improve crew visibility during final 
descent 

• Baselined two side-located habitable volumes utilizing inflatable structures technology. These 
habitable volumes are 6 m 2 3 each and can be configured as an airlock or crew sleep area 

• Changed the Transport Habitat configuration from spherical to gem-shaped 

• Improved definition of structural attachments of propulsion subsystem and habitats 

• Adopted a modular lander gear approach with updated landing gear attachment points (a fixed 
gear concept is baselined) 
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• Adopted a two engine main propulsion system configuration (single engine on each side). 
These are Shuttle orbital maneuvering engine (OME)-based engines which are required to be 
throttleable 


• Upgraded RCS thrusters to 100 lbf 
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Figure 7. The Descent-Assisted Split Habitat (DASH) lander sortie mission configuration. 


For the deployment and maintenance of a permanently crewed outpost (assumed as the follow-on step of 
lunar exploration beyond the 7-day lunar sortie missions), the DASH lander concept is reconfigurable to 
support autonomous, uncrewed delivery of outpost infrastructure (e.g., an outpost surface habitat, 
pressurized rovers, power systems, etc.) as well as resupply logistics (crew resupply, science hardware, 
spares/maintenance, and gas/water). Figure 8 illustrates a DASH lander configured for the autonomous 
delivery of a >100 m 3 outpost surface habitat designed to support a crew of 4 for 6 month missions. 
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Figure 8. The Descent-Assisted Split Habitat (DASH) lander Outpost habitat configuration. 


As per direction from the Phase 1 review panel, FaRC SACD led a multi-Center team to integrate and 
refine horizontal lander concepts developed during Phase 1. A Quality Functional Deployment (QFD) 
selection process was used to downselect to a single horizontal lander concept. Using this process, team 
members from FaRC, MSFC, and KSC provided revisions to their Phase 1 concepts, agreed upon 
evaluation criteria, and ranked concepts based on the evaluation criteria to arrive at a single concept agreed 
to by consensus. Several evaluation criteria weightings were examined which emphasized lander 
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performance supporting an outpost-class mission. For these weightings, concepts which provide large cargo 
carrying capability and which facilitated cargo deployment received high scores. Figure 9 illustrates the 
horizontal lander concept developed based on this multi-Center synthesis of concepts. This downselected 
concept has been designated “Cargo Star” (C-Star). 
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Figure 9. The Cargo Star (C-Star) lander sortie mission configuration. 


A key feature of the C-Star lander concept is facilitation of lunar surface operations including crew 
egress/ingress and deployment of large cargo. For outpost missions this includes the automated delivery of 
infrastructure elements such as the outpost surface habitat. Figure 10 illustrates the C-Star lander 
configured to deliver a 1 00 m 3 outpost surface habitat. 



Figure 10. The Cargo Star (C-Star) lander Outpost habitat configuration. 
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IV. Technology Assessment for ESAS 

The technology assessment for the ESAS activity resulted in a revised Exploration Systems Mission 
Directorate (ESMD) technology investment plan that is traceable to the ESAS architecture. To develop this 
investment plan, a rigorous and objective process was implemented which included (a) establishing 
architectural functional needs, (b) collecting, synthesizing and mapping of technology data, and (c) 
performing an objective decision analysis resulting in technology development investment 
recommendations. The investment recommendation provides budget, schedule, and center/program 
allocation to develop required technologies for the exploration architecture, as well as the identification of 
other investment opportunities to maximize performance and flexibility while minimizing cost and risk. 
Several of the primary ground rules were: 1) the recommended plan must fit within the President’s NASA’s 
FY 2006 Exploration Systems Mission Directorates budget submission to Congress, 2) all of the 
technology development activities must be mapped to architecture needs, and 3) the Technology Readiness 
Level (TRL) for each project must achieve a TRL 6 by the Preliminary Design Review of the first system 
for which it will be incorporated. 

The ESAS Technology Assessment staff consisted of an implementation team and expert assessment 
panel. The implementation team was responsible for assembling functional needs based on the ESAS 
architecture, assembling technology data sheets for technology project(s) that met these needs, and provides 
an initial prioritization of each technology project’s contribution to meeting a functional need. The expert 
assessment panel examined the functional needs and technology data sheets for missing items, performed 
the final prioritization, and assessed the figures of merit (FOMs) for each need at the architecture level. All 
results were then entered into a technology investment calculator for the decision makers use in formulating 
a technology portfolio. 

A. Technology Assessment Process 

The overall Technology Assessment Process is illustrated in Figures 1 1 through 13. The process is divided 
into three distinct steps 1) define the architecture functional needs and technology options to meet the 
requirements, 2) assess the criticality of the functional needs and the technology options, 3) prioritize the 
technology options to meet the architecture functional needs. 

The first step (Figure 11) defined the architecture and its functional needs. Architectural trade studies 
were being conducted to support the Exploration Systems Architecture Study (ESAS) for four different 
mission sets: near-term Space Station support, initial lunar short-time sorties, longer-term lunar outpost, 
and far- term Mars missions. The architectural elements (launch and in- space transportation, habitats, space 
suits, etc.) were defined based on mission requirements. For each element, the functional needs such as 
structure, propulsion, power, etc. were defined. State-of-the-art and advanced technology options were 
assessed by the architecture team and were used as a point of departure for the Technology Assessment 
Team. The architecture operational mode and elements, functional needs and technology options will 
continue to be refined until a complete architecture is defined that meets the Level 0 mission requirements 
for the mandated budget constraints. 

The functional needs for the architecture were assessed for completeness and iterated as the architecture 
changed because these activities were conducted in parallel. (Note: the functional needs will be updated to 
functional requirements later in the development cycle). In addition, the criticality of the functional needs 
as measured by the Space Exploration Figures of Merit (Safety, Affordability, Risk, Extensibility, and 
Performance) was assessed. For example, structure has a larger impact on overall performance than an 
Integrated System Health Management (ISHM) system, however, the ISHM has a larger impact on safety 
than structure. 

Technology options were identified and mapped to the functional needs. The technology options 
consisted of those identified by the architecture development team, current technology development 
programs and other possible technology solutions. The architectural elements, functional needs, and 
technology options were put into a knowledge repository for assessment and prioritization. 
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The second step in the technology assessment process (Figure 12) was to assess the technology options that 
may meet each of the mission/element/functional needs. Initially, the technologies were assessed as 
needed, desired, or not applicable. The architecture team defined the technology needs by either specifying 
state-of-the-art or a required new technology. If a technology met or exceeded the new technology 
requirement, it was designated a “must have” technology (later called a “gotta have” technology). If a 
technology option exceeded a state-of-the-art specified technology, it was designated as a desired or 
“wanna have” technology. If a technology option has the potential to be incorporated into the assessment 
process but needed to be modified or grouped with other technologies to meet a functional need, these 
technologies were further defined by the Implementation Team. If a technology only met a state-of-the-art 
specified technology, it was dropped from consideration. Also, each functional need was assessed to 
determine if at least one technology option exists to satisfy the need. 

The technology options were then sorted by "wanna have" and "gotta have" and could be manipulated 
by changing the weights on the program Figures of Merit. 
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Figure 12. Technology Assessment - Functional Needs and Technology Options Assessments 
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The third step (Figure 13) was to prioritize the technology options based on the program FOM impact, 
mission impact, element impact, functional need impact, ability of technology to meet or exceed the 
functional need, “Gotta Have” or “Wanna Have”, technology development budget, and technology 
development schedule meeting need dates, and technology development risk. A technology calculator was 
developed to adjust the weights for each of the impacts and to determine technology development cost 
needs and schedule impacts. Deliverables of the technology assessment were a prioritized list of 
technologies, technology development risk, schedule, cost, and yearly funding profiles. 

In order to do the Technology Assessment process a Management Team, an Implementation Team, and 
Expert Assessment Panel were formed. The Implementation Team interfaced with the ESAS Architecture 
Team to develop the functional needs and technology selections (either state of the art or advanced), 
developed the technology option data and maps to the functional needs/elements/missions, and the 
technology calculator. The Expert Panel assessed the criticality of the functional needs and the impact of 
the technology options to the functional needs and solicited additional technology options if required. The 
ESAS Technology Assessment team at headquarters conducted the final technology prioritization and 
developed the recommendations for the Space Exploration program. 
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B. Figures of Merit 

For the technology selection prioritization process, each of the technology needs and technology options 
were evaluated on their impact to the Exploration Systems Architecture Study (ESAS) Figures of Merit 
(FOMs) shown in Figure 14. To simplify the technology assessment process, the technology impacts on 
the FOMs were ranked at the FOM category level: Safety and Mission Success, Extensibility/Flexibility, 
Programmatic Risk, Affordability, and Performance. 
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Figure 14. ESAS Figures of Merit 


C. Functional Breakdown Structure 

1. FBS Definition Process 

In order to capture and organize technology options applicable to exploration systems, elements of 
exploration architectures were decomposed into functional groupings according to a Functional Breakdown 
Structure (FBS). Several FBSs were utilized to capture the breadth of technologies related to major 
hardware elements and associated infrastructures. These individual FBSs were derived by Technology 
Assessment Team members using their own expertise and previously developed breakdown structures. 

Each FBS consists of a table in Excel with rows used for functional groupings and columns used for 
information capture. Information is categorized by: Performance Challenges and Requirements; Assumed 
Technology; Technology Need Date; Rationale/Benefits of Assumed Technology; Data Source; Current 
State-of-the-Art; and Potential Issues/Risks. In most cases functional groupings within each FBS go 
multiple levels deep to allow sufficient technical detail to support technology assessments. 

2. Mission Classifications 

In order to better understand technology needs as a function of time, the Exploration Vision was divided 
into several missions representing different time phases. The mission classifications are ISS, Lunar Sortie, 
Lunar Outpost, and Mars. The ISS Mission performs the crew and logistics transfer functions required to 
support ISS once the Shuttle has been retired. The Lunar Sortie Mission performs the initial crewed flights 
to the Moon for brief stay times of several days. The Lunar Outpost Mission establishes a long duration 
(months) human presence on the Moon’s surface and presumably builds on the capabilities established by 
the Lunar Sortie Mission. The Mars Mission establishes initial capabilities for landing humans on the 
Martian surface and is assumed to occur after operations are established for the Lunar Outpost Mission. 
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For each of these missions a separate Excel workbook was used to organize the various mission-specific 
architectural elements. Individual sheets of the workbook contain the FBS table specific to a particular 
element of the architecture. 

3. Individual FBS Types 

There were five FBS types developed for the technology assessment activity. They are General Element, 
Systems Engineering, Communications Infrastructure, Operations, and In- Situ Resource Utilization. The 
following sections describe each of these FBS types. 


D. Functional Needs 

1. Process for Establishing Functional Needs 

Establishing the functional needs of the Exploration Systems Architecture Study (ESAS) architecture 
was accomplished using a three-step process, which included: 

- Review of the architecture requirements and related assumptions 

- Identification of system level requirements 

- Definition of critical challenges and technologies 

Due to incomplete definition of the ESAS architecture in the early stages of the study, an initial set of 
functional needs was derived from the “Point of Departure” architecture developed by Johnson Space 
Center (JSC). As the ESAS architecture matured, the needs were modified to reflect the current state of the 
ESAS architecture. 

2. Functional Needs 

Functional needs of the ESAS architecture were mapped by the NASA Langley Research Center 
(LaRC) Technology Assessment team to the Functional Breakdown Structure (FBS) described above by: 
defining the performance challenges and requirements of the ESAS architecture, determining the assumed 
technologies and associated rationale/benefits, and identifying additional applicable technologies (Table 3). 

Table 3. FBS with Functional Need Definition Columns 
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A set of performance challenges and requirements was defined for each element of the ESAS 
architecture by mapping top-down system requirements to the FBS elements. Associated technology 
technical performance measures were defined where possible for each of the requirements to aid in the 
translation of the system and subsystem level requirements into technology requirements. In the case 
where no requirement or challenge was identified within an FBS element for a particular architecture 
element, “None Identified” was noted. 

The next step in the process was to document the technology assumptions of the ESAS architecture. 
The baseline technologies that were assumed for the architecture were identified as well as the associated 
Technology Readiness Levels (TRLs). The technologies were classified as either “state-of-the-art” (SO A) 
or a critical technology development need, based on the defined TRL. The associated rationale/benefits 
were also documented along with the reference source of the information, current SOA, and potential 
issues/risks. 

The final step in the process was a bottoms-up technology identification assessment. Inventories of 
applicable technologies - additional technologies that were not included in the initial baseline assumptions, 
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were developed for each FBS element. From this inventory, those technologies that met the need date and 
addressed critical challenges were listed as Applicable Technologies on the FBS. Technical data sheets 
(TDSs) were developed for each of the applicable technologies (see section 7.0 for a description of the 
TDSs). A team of subject matter experts reviewed the TDSs and also identified additional applicable 
technologies, and generated corresponding TDSs. 

Delineation was established between the state-of-the-art (SOA) technologies, requiring minimal to no 
development, and critical technology needs, which require significant development for successful 
application to the architecture. Based on the defined TRL and need date, assumed technologies with a TRL 
of 6 or higher were classified as SOA, while those with a TRL lower than 6 were defined as a critical 
technology development need. As with the performance requirements definition, the technology 
assumptions for a Point Of Departure (POD) architecture were used initially, and were augmented as the 
ESAS architecture and technology assumptions matured. 

3. Gotta Haves and Wanna Haves 

After the functional needs were defined, the technologies that apply to them were known throughout the 
analysis as "gotta have" or "wanna have". A "gotta have" was a technology that addresses a critical 
functional need. Critical functional needs were defined as areas where technology development is required 
to fulfill the architecture requirements. A "wanna have" was a technology development that would enable 
the architecture to go beyond the stated need. For example, if in a certain area the current state of the art 
was identified by the architecture team as sufficient for the needs of the architecture, then it was not a 
"gotta have" area. However, a technology, that if developed, would enhance this area in terms of one or 
more of the five figures of merit, mission success / safety, affordability, programmatic risk, extensibility, 
and technical performance, it would be submitted to the process and considered as a "wanna have". 

4. EAP Management Matrix and FBS Needs 

The Expert Assessment Panel (EAP) Management Matrix included a combination of critical needs that 
had been approved by the ESAS Core Team and needs submitted by the EAP and agreed to be critical by a 
majority vote of the EAP members. These needs were categorized by each of the level one FBS areas. The 
other dimension of the EAP Matrix was the overall criticality and five Figures of Merit (FOMs) for each of 
the architectures, ISS, Lunar Sortie, and Lunar Outpost. The EAP members voted on the rankings to fill in 
this matrix, which was later translated back to the original FBS and input into the Space Calculator (SC) to 
impact the final analysis and technology development prioritization. 

There were both advantages and disadvantages to carrying multiple sets of needs and matrices 
throughout the assessment process. One distinct benefit, of starting the EAP Management list of needs in 
addition to the full FBS list with needs listed per element and per architecture, was that the EAP needs list 
greatly reduced the complexity, and therefore the number, of needs to be considered by the EAP and ESAS 
leadership. There were several disadvantages as well, however, all that stemmed from the full FBS and 
needs list being developed and implemented first and then the EAP Management list being created and 
maintained by a separate group within the assessment process. Extra time was required to map the EAP 
needs back to the appropriate individual FBS areas, as well as elements within each of the architectures, as 
applicable based on the relevant architectures determined by the EAP voting. This was necessary, as the 
EAP needs were not captured with element contexts. This lack of element context caused each of the needs 
versus FOM rankings to be considered the same for every element the need was mapped to for the SC. 
Although the EAP matrix was representative in general, having remained with only the full FBS for each 
element and each architecture would have allowed for further delineation between elements. 


E. Technology Options to Meet Functional Needs 

1. Overall Solicitation Process 

The solicitation of data on the many technologies under development within the agency began with 
assigning members of the implementation team, along with points of contact (POCs) located at NASA 
Langley Research Center, to each of the level two functional breakdown structure (FBS) areas. Emphasis 
was placed on getting data to satisfy critical functional needs where technology development was known to 
be needed to enable the Exploration Systems Analysis Study (ESAS) Architecture. However, inputs of 
technologies that would enhance the architecture beyond the strict need specified were strongly 
encouraged. Once all the data was collected from this group the Expert Assessment Panel (EAP) was given 
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the opportunity to review what had been gathered and submit any additional information they felt was 
missing to directly address either a critical or non-critical functional need. 

2. Technology Data Sheets 

The Technology Data Sheet (TDS) was developed with the specific information needed by the Space 
Calculator (SC). An example data sheet can be seen in Figure 15. There were three categories of data 
included in the TDS, vital, enhancing, and supporting, based on how the information impacted the analysis 
process within the SC. 

The vital pieces of information were the Technology Project Name, Architectures Impacted by 
Technology, Current TRL, Target Year for TRL=6, Total Cost for TRL=6 (millions), Research Degree of 
Difficulty, and Duration to TRL 6. The Technology Project Name, is the title of the technology being 
documented. The Architectures Impacted by Technology is seen on the TDS as a row of buttons that each 
say "yes” or ’’no". The responses captured, when these indicators are clicked, form the start of the mapping 
process that occurs with all TDSs to identify their architecture and element applicability. The remaining 
pieces of vital information are all included in the Technology Maturation section of the TDS. The current 
TRL is input as a value of a single digit from 1 to 9 based on the standard NASA TRL scale, included as 
Appendix A2. The target year for TRL=6 is the four digit year in which the technology is expected to 
reach TRL 6 status. The total cost is the amount, in millions of dollars, that this development of the 
technology from where it is currently in TRL to a TRL of 6. The Research Degree of Difficulty, commonly 
referred to as RD3 or RD 3 , is an indication of how likely the technology development will be to reach its 
milestones. RD3 is input as a single digit ranging from 1 to 5, and detailed definitions of these levels are 
included in Appendix A3. Duration to TRL 6 is simply the number of years of development expected to be 
required to mature the technology from its current TRL to a TRL of 6. 

The enhancing areas of the TDS add important details to those collected in the vital areas. The 
Percentage Cost by Center, or center splits, is the percentage of the total technology development funding 
that will go directly from NASA Headquarters to that center regardless of where the funding may go from 
the center, such as to industry or academia. These percentages must overall add up to 1 00% and are 
entered as just the numerical value of the percentage without the % symbol, e.g. 100 not 100%. The other 
enhancing area is the Technology Development Schedule. This is a list of the major milestones along the 
development path, what year they will occur in, the TRL the milestone will mark the technology reaching, 
and the cost, in millions of dollars, for that milestone to be reached. This is considered enhancing as it adds 
granularity to the overall cost associated with the development and enables a cost profile to be built as 
opposed to assumed based only on the overall total cost. 

The remainder of the data collected on the TDS is supportive of the decision making process. The 
Contact Information section of the TDS captures the name, phone numbers, center affiliation, and email 
address for both the primary and secondary POCs for the technology development documented in the TDS. 
This is used to contact the most knowledgeable person if there are any questions during the assessment 
process. The Technology Description allows someone not familiar with the particular technology 
development submitted to make a more informed decision. The Technical Performance Measures and 
Dependence on Other Technologies to Meet Capability Expectations areas of the TDS as well as the 
Figures of Merit Impacts and Rationales all add further details to the knowledge available and confidence 
in the vital and enhancing information submitted in other sections, so the development being described may 
be properly assessed. The Technical Performance Measures, TPMs, list the metrics to gauge the 
technology's development against. The current state of the art and the projected value for this metric are 
recorded as well as a probability, entered as a percentage, that the projected value can be achieved by the 
proposed development. Without these values it is difficult to ascertain how much benefit a technology will 
have on the architecture if developed. The Dependence on Other Technologies to Meet Capability 
Expectations is important as it allows leaders to consider suites or groups of technologies that should be 
developed and assessed together to have an architecture functional need completely met. The Figures of 
Merit Impact Ratings and Rationales provide insight as to not only how the technology would impact the 
FOMs but also why it would have that impact and for which architectures. These fields are directly 
controlled by the selections of Architecture Applicability at the top of the TDS. If "no" was clicked than 
these fields will be grayed out and locked, if "yes" was clicked than the fields will be opened for use. The 
impact ratings are a one digit value ranging from 1 to 5 as described by the scale on the left hand side of the 
section. The rationales noted should be specific to the particular architecture being evaluated. The Other 
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Comments fields are the POC's chance to make note of any other pieces of information that the assessment 
or leadership teams should know about the technology and/or its development. 


Dependence on Other Technologies to Meet Capability Expectatioi 


Technologies 

Developers 

Funded or Unfunded 
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Figure 15. Technology Data Sheet 
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3. Existing Projects 

Also included as data input into the analysis process was that from the existing projects within the 
agency. Quad charts were gathered for each of the projects within the Human Systems Research & 
Technology (HSR&T), Exploration Systems Research & Technology (ESR&T), and Prometheus 
development programs. Legacy projects were not included, as they were due to be terminated at the end of 
FY'05. The existing projects were treated nearly identical to the TDSs. Each was reviewed and assigned to 
applicable FBS areas, architectures, and elements with the aid of the NASA Langley POCs. A further 
detailed mapping of HSR&T projects to the previously submitted TDSs was provided by the 
Implementation Team and EAP members that work on those TDSs. The vital information for the SC, and 
as much enhancing information as possible, was extracted from the quad charts and captured in an MS 
Excel file for inclusion in the SC along with similar data from the TDSs. 


F. Technology Prioritization Assessment Process 

A capability was provided to the ESAS team to rack and stack the necessary technology solutions to 
meet the three primary missions for the Space Exploration initiative and was called the Space Calculator. 
The foundation of the Space Calculator approach was based on the research conducted under the National 
Institute of Aerospace Grant number NCC- 1-02043 entitled “Integration Plan for Future NASA Aircraft 
research Program”. The robustness of the final tool delivered to the ESAS team allowed for the variation in 
annual budget, the specification of the TRL 6 date for each mission, and the flexibility to change the 
solutions, budget distributions, priorities, and durations. The results of the calculator execution would allow 
for traceability of the decisions made for the ESAS recommendations. By combining inputs from the 
Implementation Team and the Expert Assessment Panel, the final plan could be developed in a dynamic 
and iterative fashion. This information needed for the Space Calculator is illustrated in Figure 16. 

Two primary tiers of information that were necessary to build the Calculator included: 

• Relationship of the mission critical needs to the Figures of Merit (FOM) 

• Relationship of the EAP technology solutions to the critical needs for each mission 

The common theme between the two tiers was the definition of the mission architecture and the 
associated elements necessary to accomplish each mission’s list of critical needs. The Architecture 
provided this taxonomy and element list of which was extensively utilized in the Calculator. At the top tier 
was the EAP Management Matrix mapped to the missions FOMs. The lower tier of information was 
referred to as the “Planning Matrix”, which related the technology solutions identified from the EAP to the 
critical functional needs defined by the ESAS core team as structured by the Architecture team’s taxonomy. 
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EAP 


Core Team 



ESAS Architecture Functional 
Needs Information Mapped to 
Taxonomy 


Investment 

Recommendations 

Identified 


Figure 16. Information Flow of the Space Calculator 


In the EAP Management Matrix, a qualitative mapping between the critical needs of the element FBS to 
the FOMs was established via a voting procedure during the final meeting. The qualitative mapping was 
then translated into a quantitative scale as defined by: 

• High impact = 9 

• Medium impact = 7 

• Fow impact = 1 

• Not applicable = 0 

• Negative = -2 

Additionally, each of the FBS critical needs was classified in terms of criticality to each mission with 
the same qualitative definitions as above, but with a slight modification to the quantitative score where a 
high impact was defined as a value of 10. From the quantitative mappings, sensitivities of the mission 
elements could be determined. 

In the Planning Matrix for the EAP solutions to the mission element critical needs, a similar qualitative 
mapping was conducted. However, the qualitative scale was modified to: 

• Strongly exceeds need = 9 

• Exceeds need = 7 

• Meets need = 1 

• Not applicable = 0 

• Does not meet need — -2 
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By default, each of the solutions proposed by the EAP was assumed to meet the need. Hence, within the 
Planning Matrix, a solution was mapped to the appropriate element FBS for a given mission as listed below 
in Table 4. 

For each EAP solution, the following reference information was obtained: 

• TRL = 6 date 

• Total cost to reach TRE = 6 

• RD3 

• Annual funding profile 

• Mission applicability 

Based on the two tiers of matrices and the information for each EAP solution, the foundation of the 
Space Calculator was established. Additional features were added for robustness, flexibility, and 
extensibility. 

The main page of the calculator is where “what-if ’ games can be played, while the supporting tabs allow 
the user to make fundamental changes in the assumptions. The main page is divided into four primary 
regions: budget information, input weightings and required TRL=6 dates, the rack and stack of solutions 
and associated schedules, and the resulting portfolio impact on RD3 and center splits. 

The budget profile allows the user to visualize the resources used by the funded technology solutions 
versus the maximum allowable funding. An allowable yearly budget profile is input, giving the Space 
Calculator’s algorithm a limit to avoid exceeding when appropriating funds to technology solutions. 
Additionally, the funding used by “Gotta Have” technology solutions is shown to demonstrate the level of 
funding they require and also to allow for visualization of additional technology solutions that could 
possibly be funded. An adaptable generic technology funding profile was also provided on the main page, 
which shapes the required funding of a technology solution over its duration if a funding profile was not 
defined. 

In the middle section of the Space Calculator, the user has the ability to change the relative importance 
amongst top-level FOMs, in addition to mission preferences, and individual element priorities for a given 
mission. Altering these values will reprioritize the technology solutions such that the chosen solutions to 
fund may change in addition to the schedules. Additionally, the user has the freedom to change the required 
TRL=6 date for each of the missions, which will alter the necessary funding and schedule profile. 

To the right of the main page, for a given set of inputs and annual funding allotments, the Space 
Calculator will rack and stack the full set of EAP solutions, as broken into the four missions. The basis of 
the rack and stack is determined from the impact of the solution to the element FBS, the FOMs, and 
whether the solution is a “Gotta Have” or a “Wanna Have”. When funding technology solutions, the 
calculator activates all “Gotta Haves” first. “Gotta Have” solutions begin being funded immediately after 
the previous mission’s deadline if this allows for the solution to meet the current mission’s TRL = 6 date. If 
this is not possible, the solution is instead funded sufficiently early to meet the required deadline. Once all 
“Gotta Have” solutions have been funded, the calculator then begins funding “Wanna Have” solutions. 
Should the allowable budget be exceeded by only “Gotta Have” solutions, then the calculator assumes that 
one or more of the missions may be impossible to fund and suggests that the user inspects the various 
inputs. Otherwise, “Wanna Have” solutions are funded only if they can be funded continuously without the 
total budget exceeding the allowable budget input by the user. If the budget is completely used up or the 
calculator exhausts all given technology solutions, their respective information are then shown on the main 
calculator page, ranked by their “Gotta Have” status and their impact to the defined Figures of Merit. If a 
solution is funded and meets the required mission TRL = 6 date, it is color coded as green. If a solution that 
was a “Gotta Have” for any of the missions is funded but not meeting a particular mission TRL = 6 data, it 
is color coded as yellow to prompt the user to investigate the schedule for the solution. If a solution is color 
coded as grey, it is not funded in that mission time frame. 

To the lower left portion of the Space Calculator are the results of the annual funding and schedule 
assumptions. The RD3 of the funded solutions is shown in a pie chart. The number of active solutions 
proposed by each center is also shown. The right two pie charts demonstrate the percentage of funding 
going to a given center. The top right pie chart shows the funding breakdown for a specified year while the 
bottom right pie shows the total funding breakdown over the life of the program. Radar charts at the bottom 
of the page display the relative impact to the top level figures of merit for the funded technology solutions 
versus the total solution portfolio for each mission. 

Finally, to make the calculator more robust, options were added to allow the user to override the 
calculator’s decisions. An earliest start year could be input for any technology solution, which tells the 
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calculator that a given solution may not be started until the specified year for reasons not otherwise 
accounted for in the input information. Additionally, a human override is allowed that will make the 
calculator begin funding a technology in a specific year, regardless of other inputs. 


Table 4. Mapping Assumptions of EAP Solutions to Architecture Elements and FBS 
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Table 4. Mapping Assumptions of EAP Solutions to Architecture Elements and FBS (cont.) 


Submitted Solution / Key Word(s) 
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V. Summary 

The exploration systems analysis capabilities applied and/or developed during the ESAS activity for 
strategic assessment, architecture development and technology assessment were identified as needed in 
support of a continued ESMD decision support system. The ESMD Directorate Integration Office (DIO) at 
NASA Headquarters established an on-going task to facilitate an “ESAS-like” strategic analysis capability 
to help in the establishment and continuous assessment of Level 1 requirements in support of the Vision for 
Space Exploration. The products of this task include alternative advanced exploration architectures, 
associated advanced concepts and technology performance needs, assessments of architecture sensitivities 
to requirements and technology changes using established Figures of Merit, technology assessments and 
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strategic technology portfolios, and the integration of these assessments into effective information transfer 
mechanisms. This is a systems analysis activity that will repeat on an annual basis (see figure 17) as 
explorations systems are developed and refined in support of the Vision for Space Exploration. The driving 
factor for deliverables is the annual POP call in the spring. The cycle is driven by prioritized capability 
needs provided by HQ sponsored requirements definition studies and by the Level 2 program offices 
assessed against ongoing technology development efforts. The significant gaps and overlaps are then 
adjudicated leading to an integrated technology investment portfolio recommendation that feeds into the 
POP call. Inherent in this process is also a continuous improvement in the analytical capabilities 
supporting the decision making process. 
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Figure 17. Annual Exploration Systems and Technology Assessment Cycle 
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